A typical distributed computer system, as illustrated in FIG. 1, includes multiple client computers 102 which ask one or more generic application servers 104 to provide various services. These requests may ask the server to provide many types of services. For example, a request may ask the server to authenticate a user, provide access to files or data, send or receive email, or provide Web access.
To start the process, a client 102 sends one or more requests to the server 104 over a connection 108 between the client and the server. The server then fulfils the request, which, in some cases, may involve obtaining data over one or more connections 110 to various databases 106.
A client request can be generated, for example, by a Web browser or some other application. The client request is then sent by the client computer to the server using a protocol that is specific to the type of system. Generally, the system supports a protocol that is either a “connection-full” or a “connectionless” protocol.
Using a connection-full protocol, a client makes a connection to the server, and that connection can be maintained throughout multiple message exchanges between the client and server. Even through periods of idleness, when no messages are being exchange, the client and server maintain the connection.
One advantage to using a connection-full protocol is that the client is guaranteed a connection resource when the client has a message to send to the server. In addition, it is easier for the server to keep track of which messages are associated with which client, and the state of the client application. A disadvantage to using a connection-full protocol, however, is that the semi-permanent connections inefficiently consume server resources. Even though the channel may be idle (i.e., the client and server are not exchanging any information), the server must expend resources to maintain the channel and information relating to the client, thus making those resources unavailable to other clients.
Hyper Text Transfer Protocol (HTTP) is an example of a connectionless protocol that is commonly used in Internet applications. Using a connectionless protocol, each time a message needs to be transferred between the client and the server, a connection is established, the message is transferred, and the connection is terminated.
One advantage to using a connectionless protocol is that the available server resources are more efficiently utilized. Essentially, server resources relating to client-server communications are consumed only when information needs to be transferred between the client and server. One disadvantage to using a connectionless protocol, however, is that the connection establishment and termination process must be performed for each message that needs to be exchanged. In addition, client state information (e.g., authentication information) often needs to be passed to the server again.
Often, a client would like the server to perform multiple, related actions. For example, a client may ask a server to alter multiple records stored in a particular database table. In some systems, these multiple actions are managed using “transaction processing,” which is a technique for processing a set of related requests. Specifically, a “transaction” is a way of grouping a set of requests so that all requests are either completed or all requests fail. For example, the requests could be to perform an input/output (I/O) operation, requests to update a screen, or requests to store or retrieve data to memory, tape, or a database. In the context of database transactions, transaction processing enables modifications to a database to be controlled so that system failures do not affect the correctness or integrity of the database.
Using transaction processing, the separate operations that comprise the transaction must be executed atomically, meaning that once the transaction begins to execute, all of its operations must be completed. If a failure interrupts the transaction, the part of the transaction that has been completed must be rolled back. The rollback process returns the system to a previously known and consistent state, as if the transaction had never occurred. If a transaction is completed, the changes are “committed,” and if the transaction is interrupted or explicitly cancelled, it is considered to be “aborted.”
Transaction processing has several advantages. First, the atomicity characteristic of a transaction means that each transaction is treated as all-or-nothing. If a transaction commits, all of its requested effects remain. If a transaction aborts, no requested changes are made to the system. For example, if a transaction relates to modifying a database, the database will not include partial modifications that make the database records inconsistent.
Some systems enable transactions to be “isolated” from each other, meaning that updates of concurrent, incomplete transactions are separated from each other. Thus, for example, other clients will not see the changes to database records until those changes are committed. This isolation characteristic also means that database manipulation in the context of a transaction enables the client to keep a coherent view of the database. Thus, the database will not appear to change once a client has opened a transaction. Although isolation is not a requirement of a transaction, many systems provide it, often providing multiple levels of isolation.
Using a connectionless protocol, separate messages that comprise a particular transaction could come into the server out of order, in some cases. This may occur, for example, when multiple client threads are issuing requests within the context of a single transaction, or if an unreliable protocol is being used. Generally, prior art transaction managers are unable to handle out of order requests.
In some system architectures, data can be referenced at different server locations. For example, certain data may have been moved, and the server that initially provided access to that data maintained the data's forwarding address. In these circumstances, when the server receives a request for that data, the server can issue a redirect message to the client, indicating that the data is accessible to another server (i.e., at the forwarding address). HTTP is an example of a protocol that offers redirect services.
In prior art systems, these redirect messages are handled by the client application, such as the client's Web browser. After receiving the message, the application must either send a new request to the appropriate server, or must fail the request. Thus each application must include the ability to handle these redirect messages, placing an additional burden on application designers.
A server may need to redirect one or more, but not all, requests that are made in the context of a transaction. These redirect requests in the context of transactions are not well handled by prior art systems.
What is needed is a system and method that has the advantages of both a connectionless and a connection-full protocol, without the accompanying disadvantages. Specifically, what is needed is a system and method that efficiently uses server resources, without requiring a connection to be established and terminated each time a message needs to be transferred. Further needed is a system and method that enables transaction processing to be performed even when the server receives the transaction's requests out of order. Further needed is a system and method for a client computer to handle redirect requests without involving the associated client application, including the ability to handle redirect requests in the context of a transaction.